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AMENDMENTS TO THE CLAIMS 
Please amend Claims 1, 4, 6, 9, 11, and 14 as follows: 



1 1 . (Currently Amended) A process for determining latency between multiple servers 

2 and a client across a network in a computer environment, comprising the steps of: 

3 receiving a request for latency metrics on a cont e nt server; 

4 wherein said latency metric request specifies a particular client; 

5 providing a latency management table; 

6 wherein said latency management table comprises a list of IP addresses along with 

7 corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop 

8 counts, and Round Trip Times (RTT); 

9 looking up the latency metric for said client in said latency management table; 

1 0 sending said latency metric to the requesting server; 

1 1 wherein only the BGP hop count for said client in said latency management table is 

12 used for said latency metric upon an initial request for said client; and 

1 3 wherein the dynamic hop count and RTT data for said client in said latency 

14 management table are used for said latency metric for subsequent requests for 

15 saidcHent. 

1 2. (Original) The process of Claim 1, further comprising the steps of: 

2 sending periodic latency probes to the IP addresses in said latency management 

3 table; 

4 receiving response packets for said latency probes; and 

5 recording the dynamic hop count and latency (RTT) data in said latency 

6 management table. 
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1 3. (Original) The process of Claim 2, wherein periodic latency probes are sent to a 

2 higher level server of a client by masking said client's IP address in said latency 

3 management table. 

1 4. (Currently Amended) The process of Claim 1, further comprising the steps of: 

2 receiving requests for a content server address from said client; 

3 sending a latency metric request to the appropriate cont e nt servers; 

4 receiving latency metric data from said cont e nt servers; 

5 determining the optimal content server for said client; and 

6 sending said optimal content server's address to said client. 

1 5. (Previously Presented) The process of Claim 4, wherein said determining step 

2 gathers the expected latency metrics and uses the inverse relationship of the dynamic 

3 hop counts in said latency metric data in a weighted combination with the RTT in 

4 said latency metric data to determine which latency metric data indicates the optimal 

5 content server. 

1 6. (Currently Amended) An apparatus for determining latency between multiple 

2 servers and a client across a network in a computer environment, comprising: 

3 a module for receiving a request for latency metrics on a cont e nt server; 

4 wherein said latency metric request specifies a particular client; 

5 a latency management table; 
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6 wherein said latency management table comprises a list of IP addresses along with 

7 corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop 

8 counts, and Round Trip Times (RTT); 

9 a module for looking up the latency metric for said client in said latency 

1 0 management table; 

1 1 a module for sending said latency metric to the requesting server; 

12 wherein only the BGP hop count for said client in said latency management table is 

13 used for said latency metric upon an initial request for said client; and 

14 wherein the dynamic hop count and RTT data for said client in said latency 

15 management table are used for said latency metric for subsequent requests for 

16 said client. 

1 7. (Original) The apparatus of Claim 6, further comprising: 

2 a module for sending periodic latency probes to the IP addresses in said latency 

3 management table; 

4 a module for receiving response packets for said latency probes; and 

5 a module for recording the dynamic hop count and latency (RTT) data in said 

6 latency management table. 

1 8. (Original) The apparatus of Claim 7, wherein periodic latency probes are sent to a 

2 higher level server of a client by masking said client's IP address in said latency 

3 management table. 

1 9. (Currently Amended) The apparatus of Claim 7, further comprising: 
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2 a module for receiving requests for a content server address from said client; 

3 a module for sending a latency metric request to the appropriate cont e nt servers; 

4 a module for receiving latency metric data from said cont e nt servers; 

5 a module for determining the optimal content server for said client; and 

6 a module for sending said optimal content server's address to said client. 

1 10. (Previously Presented) The apparatus of Claim 9, v^herein said determining module 

2 gathers the expected latency metrics and uses the inverse relationship of the dynamic 

3 hop counts in said latency metric data in a v^eighted combination with the RTT in 

4 said latency metric data to determine v^hich latency metric data indicates the optimal 

5 content server. 

1 11. (Currently Amended) A program storage medium readable by a computer, tangibly 

2 embodying a program of instructions executable by the computer to perform method 

3 steps for determining latency between multiple servers and a client across a network 

4 in a computer environment, comprising the steps of: 

5 receiving a request for latency metrics on a cont e nt server; 

6 wherein said latency metric request specifies a particular client; 

7 providing a latency management table; 

8 wherein said latency management table comprises a list of IP addresses along with 

9 corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop 

10 counts, and Round Trip Times (RTT); 

1 1 looking up the latency metric for said client in said latency management table; 

12 sending said latency metric to the requesting server; 
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13 wherein only the BGP hop count for said cHent in said latency management table is 

14 used for said latency metric upon an initial request for said client; and 

1 5 wherein the dynamic hop count and RTT data for said client in said latency 

16 management table are used for said latency metric for subsequent requests for 

17 said client. 

1 12. (Original) The method of Claim 11, further comprising the steps of: 

2 sending periodic latency probes to the IP addresses in said latency management 

3 table; 

4 receiving response packets for said latency probes; and 

5 recording the dynamic hop count and latency (RTT) data in said latency 

6 management table. 

1 13. (Original) The method of Claim 12, wherein periodic latency probes are sent to a 

2 higher level server of a chent by masking said client's IP address in said latency 

3 management table. 

1 14. (Currently Amended) The method of Claim 1 1 , further comprising the steps of: 

2 receiving requests for a content server address from said client; 

3 sending a latency metric request to the appropriate cont e nt servers; 

4 receiving latency metric data from said cont e nt servers; 

5 determining the optimal content server for said client; and 

6 sending said optimal content server's address to said client. 
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1 15. (Previously Presented) The method of Claim 14, wherein said determining step 

2 gathers the expected latency metrics and uses the inverse relationship of the dynamic 

3 hop counts in said latency metric data in a weighted combination with the RTT in 

4 said latency metric data to determine which latency metric data indicates the optimal 

5 content server. 
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